ACD capabilities have recently become a standard part of most call center environments. ACD involves receiving relatively large numbers of calls and distributing them according to various algorithms to agents and/or automatic equipment for service and processing.
In more recent systems, it is known to optimize the call distribution function by matching particular calls with particular agents. For example, calls to a credit card servicing company might be classified, based upon calling telephone number, into one of several groups which indicate whether the caller is a “gold” member or a “platinum” member. Depending upon the group into which the incoming call is classified, the call would then be placed into one of several different queues, whereby callers with the highest level of membership will be serviced faster.
Many other examples exist in present ACD technology for optimizing the caller's experience. For example, callers may be matched to specialized servicing agents that speak particular languages, are familiar with particular issues, etc. Most systems also provide that the incoming caller's identification can be ascertained either from the calling number identification or other user input such as an account number. Such a step permits the system to retrieve a database record with detailed information regarding the customer's account, and display such database record to an agent prior to connecting the caller with the agent.
The foregoing and other ACD capabilities require somewhat significant intelligence to be built into the switching arrangement at the customer premises. FIG. 1 shows a very high level conceptual diagram of a prior art system for implementing an exemplary embodiment of the foregoing system. Server 101 represents a traditional ACD platform including queuing capabilities, call forwarding and call routing, directory information to permit call forwarding by name, and other similar items.
Communications link 102 is a full-function CTI link which connects a business application server represented by 103 to the traditional ACD platform 101. Such a CTI link may operate with the ECMA standard protocol, for example. Application server 103 would usually contain software to execute a standard business call center function, such as order entry. The application server 103 may also contain a database of customer information for use by agents when calls are distributed.
In the arrangement of FIG. 1, application server 103 may invoke and control the robust set of features present in ACD platform 101. However, ACD platform 101 is typically a proprietary and relatively expensive system with little flexibility. Applications developers writing software to serve as an application 103 must presume that a full set of ACD capabilities is available at the ACD platform 101. Accordingly, if a business only has a basic switching environment without a full set of ACD capabilities, the arrangement of FIG. 1 will not work because the primitive functions resident in a conventional switching environment without ACD capabilities are insufficient to meet the needs of a typical application 103.
FIG. 2 depicts a more advanced prior art system for implementing ACD capabilities. In FIG. 2, the telephony environment is shown as block 201 and, unlike the prior arrangement of FIG. 1, it does not contain ACD capabilities. Instead, telephony environment 201 may be a basic switching system such as a PBX. In newer environments, the telephone environment may instead consist of a packet telephony network, and may thus include a H.323 gatekeeper, or a proxy or pass-through server in a session initiation protocol (SIP) environment. Techniques of interfacing applications computers into both of these packet telephony environments are described in U.S. Pat. No. 6,201,805 and co-pending application Ser. No. 10/092,832, owned by the Assignee of the present invention.
In the arrangement of FIG. 2, the telephony environment 201 includes only primitive switching functions such as connecting calls between particular devices or ports based on an input telephone number. The telephony environment 201 would normally contain no “intelligence” and thus, is not capable of routing calls based upon user name, queuing calls, matching calls with customer database records, etc. These functions, typically part of any ACD system, must therefore be separately implemented in software that controls the primitive functions of the telephony environment 201.
In furtherance of the above, queuing and distribution software 203 issues appropriate primitive call control commands over link 204 into the telephony environment in order to cause the telephony environment 201 to execute the primitive switching functions required to accomplish the functionality of an ACD system. The CTI application server 202 runs a separate business application (e.g. order entry), which is most often written independently of queuing and distribution software 203. If the CTI application server 202 provides CTI call control functions, it is usually arranged to provide only the primitive CTI functions available from the telephony environment 201 and not the complete set of ACD functions implemented in queuing and distribution software 203.
The system in FIG. 2 permits a non-intelligent switch (e.g., 201) to be utilized as an ACD system by writing additional software 203. However, the customer's business application 202 does not have a global view of the combined system including functions implemented in software 203, and cannot take advantage of the ACD capabilities in queuing and distribution software 203. Additionally, the business application 202 can only issue primitive switching commands to the switch 201 because switch 201 can only understand and implement a very primitive set of functions such as connecting and disconnecting calls, sending call completion events, etc. No identity- or skills-based call routing, queuing, etc. is available. This makes the application development and the design of call flows more difficult and cumbersome.
The prior art therefore typically trades-off between two competing requirements. The arrangement of FIG. 1 permits the business application 103 to use a full and robust set of call control commands and have full control over the way calls flow through the ACD system. However, an intelligent, complex, and often proprietary ACD platform 101 is required. On the other hand, the arrangement of FIG. 2 permits ACD capabilities to be implemented as a supplement to a non-intelligent switch or other telephony environment interface. However, the business application and the ACD software are often independent and the business application therefore does not have full control of the combined system and is unable to make use of a full and robust set of call control functions.